GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Representational State Transfer</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading">Representational State Transfer</h1>

</header>

</div>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="de" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="de" dir="ltr">Representational State Transfer (abgekürzt REST) ist ein <a href="Paradigma" title="Paradigma">Paradigma</a> für die <a href="Softwarearchitektur" title="Softwarearchitektur">Softwarearchitektur</a> von <a href="Verteiltes_System" title="Verteiltes System">verteilten Systemen</a>, insbesondere für <a href="Webservice" title="Webservice">Webservices</a>. REST ist eine Abstraktion der Struktur und des Verhaltens des <a href="World_Wide_Web" title="World Wide Web">World Wide Web</a>. REST hat das Ziel, einen Architekturstil zu schaffen, der den Anforderungen des modernen Web besser genügt. Dabei unterscheidet sich REST vor allem in der Forderung nach einer einheitlichen Schnittstelle (siehe Abschnitt <a href="#Prinzipien">Prinzipien</a>) von anderen Architekturstilen.

Der Zweck von REST liegt schwerpunktmäßig auf der <a href="Maschine-zu-Maschine-Kommunikation" class="mw-redirect" title="Maschine-zu-Maschine-Kommunikation">Maschine-zu-Maschine-Kommunikation</a>. REST stellt eine einfache Alternative zu ähnlichen Verfahren wie <a href="SOAP" title="SOAP">SOAP</a> und <a href="Web_Services_Description_Language" title="Web Services Description Language">WSDL</a> und dem verwandten Verfahren <a href="Remote_Procedure_Call" title="Remote Procedure Call">RPC</a> dar. Anders als bei vielen verwandten <a href="Architektur_(Informatik)" title="Architektur (Informatik)">Architekturen</a> kodiert REST keine Methodeninformation in den <a href="Uniform_Resource_Identifier" title="Uniform Resource Identifier">URI</a>, da ein URI nur den Ort (URL) oder Namen (URN) einer Ressource angibt, nicht aber die Funktionalität, die der Web-Dienst zu der Ressource anbietet. Der Vorteil von REST liegt darin, dass im WWW bereits ein Großteil der für REST nötigen Infrastruktur (z. B. Web- und Application-Server, <a href="Hypertext_Transfer_Protocol" title="Hypertext Transfer Protocol">HTTP</a>-fähige Clients, <a href="Hypertext_Markup_Language" title="Hypertext Markup Language">HTML</a>- und <a href="Extensible_Markup_Language" title="Extensible Markup Language">XML</a>-Parser, Sicherheitsmechanismen) vorhanden ist und viele Web-Dienste per se REST-konform sind. Eine Ressource kann dabei über verschiedene <a href="Internet_Media_Type" title="Internet Media Type">Medientypen</a> dargestellt werden, auch Repräsentation der Ressource genannt.

So ist ein <a href="Online-Dienst" class="mw-redirect" title="Online-Dienst">Online-Dienst</a>, der lediglich unveränderte Seiteninhalte nach dem Internetstandard HTTP anbietet, bereits REST-konform. Dynamisch erzeugte Seiten folgen diesem Paradigma jedoch oft nicht. So bieten beispielsweise Nachrichtenseiten sich ständig ändernde Informationen mit sowohl unterschiedlichem Format als auch Inhalt an, die nur schwer automatisch verarbeitet werden können. Bliebe das Format unverändert, so wäre eine wichtige REST-Eigenschaft erfüllt. So wäre eine Webseite, auf der ständig die aktuelle Uhrzeit in immer demselben Format abrufbar ist, REST-konform.

Die Bezeichnung „Representational State Transfer“ soll den Übergang vom aktuellen Zustand zum nächsten Zustand (state) einer Applikation verbildlichen. Dieser Zustandsübergang erfolgt durch den Transfer der Daten, die den nächsten Zustand repräsentieren.<a href="#cite_note-fielding_experiences-1">[1]</a>

<div class="mw-heading mw-heading2"><h2 id="Geschichte">Geschichte</h2></div>

Das REST-Paradigma entwickelte sich aus dem 1994 von <a href="Roy_Fielding" title="Roy Fielding">Roy Fielding</a> entworfenen HTTP Object Model. Fielding entwickelte seine Idee von einem einheitlichen Konzept über die Jahre weiter, bis er 2000 den REST-Architekturstil im Rahmen seiner <a href="Dissertation" title="Dissertation">Dissertation</a> veröffentlichte.<a href="#cite_note-2">[2]</a> Das <a href="Programmierparadigma" title="Programmierparadigma">Programmierparadigma</a> der „RESTful Application“ wurde allerdings häufig falsch umgesetzt und findet erst seit 2014 Anklang in der Welt des World Wide Web. In seiner Arbeit geht Fielding dabei auf die verschiedenen Anforderungen ein, die für die Webarchitektur wichtig sind.

<div class="mw-heading mw-heading2"><h2 id="Prinzipien">Prinzipien</h2></div>

Der Architekturstil verweist auf sechs Eigenschaften, die ein Dienst haben muss. Dabei ist nicht festgelegt, wie diese Prinzipien implementiert werden müssen. Fielding beschreibt für jedes Architekturprinzip dessen Vor- und Nachteile.<a href="#cite_note-3">[3]</a>

<div class="mw-heading mw-heading3"><h3 id="Client-Server">Client-Server</h3></div>

Es gilt generell die Anforderung, dass alle Eigenschaften der <a href="Client-Server-Architektur" class="mw-redirect" title="Client-Server-Architektur">Client-Server-Architektur</a> gelten. Dabei stellt der Server einen Dienst bereit, der bei Bedarf vom Client angefragt werden kann. Der Hauptvorteil dieser Anforderung ist die einfache <a href="Skalierbarkeit" title="Skalierbarkeit">Skalierbarkeit</a> der Server, da diese unabhängig vom Client agieren. Dies ermöglicht des Weiteren eine unterschiedlich schnelle Entwicklung der beiden Komponenten.

<div class="mw-heading mw-heading3"><h3 id="Zustandslosigkeit">Zustandslosigkeit</h3></div>

Jede REST-Nachricht enthält alle Informationen, die für den Server bzw. Client notwendig sind, um die Nachricht zu verstehen. Weder der Server noch die Anwendung soll Zustandsinformationen zwischen zwei Nachrichten speichern. Man spricht daher von einem <a href="Zustandslosigkeit" title="Zustandslosigkeit">zustandslosen</a> (englisch: stateless) Protokoll. Jede Anfrage eines Clients an den Server ist insofern in sich geschlossen, als dass sie sämtliche Informationen über den Anwendungszustand beinhaltet, die vom Server für die Verarbeitung der Anfrage benötigt werden.

Zustandslosigkeit in der hier beschriebenen Form begünstigt die <a href="Skalierbarkeit" title="Skalierbarkeit">Skalierbarkeit</a> eines Webservices. Beispielsweise können eingehende Anfragen im Zuge der <a href="Lastverteilung_(Informatik)" title="Lastverteilung (Informatik)">Lastverteilung</a> unkompliziert auf beliebige Maschinen verteilt werden: Da jede Anfrage in sich geschlossen ist und Anwendungsinformationen somit ausschließlich auf der Seite des Clients vorgehalten werden, ist auf der Seite des Servers keine Sitzungsverwaltung erforderlich. In der Praxis nutzen deswegen viele HTTP-basierte Anwendungen <a href="HTTP-Cookie" title="HTTP-Cookie">Cookies</a> und andere Techniken, um Zustandsinformationen auf der Client-Seite zu behalten. Weiterhin begünstigt wird die Ausfallsicherheit, weil die Zustandslosigkeit fordert, dass transaktionale Datenübertragung in einem einzigen Seitenaufruf erfolgt. Die Zustandslosigkeit bringt dabei aber den Nachteil mit, dass sich die Netzwerkperformance verschlechtert. Da bei jeder Abfrage alle Informationen zum Verstehen mitgeschickt werden müssen, sind aufwendigere Abfragen nötig, als wenn sich der Server die Interaktionen merken würde.

<div class="mw-heading mw-heading3"><h3 id="Caching">Caching</h3></div>

<a href="HTTP_Caching" title="HTTP Caching">HTTP Caching</a> soll genutzt werden, wobei gilt: Eine Anfrage, die nicht gestellt werden muss, ist die schnellste Anfrage. Fielding führt dabei den Nachteil auf, dass der Client auf veraltete Cache-Daten zurückgreifen könnte, statt die neue Ressource abzufragen.

<div class="mw-heading mw-heading3"><h3 id="Einheitliche_Schnittstelle">Einheitliche Schnittstelle</h3></div>

Dies ist das Hauptunterscheidungsmerkmal von allen weiteren Architekturstilen. Dabei besteht diese aus vier weiteren Eigenschaften. Ziel ist die Einheitlichkeit der Schnittstelle und somit ihre einfache Nutzung.

<div class="mw-heading mw-heading4"><h4 id="Adressierbarkeit_von_Ressourcen">Adressierbarkeit von Ressourcen</h4></div>

Jede Information, die über einen URI kenntlich gemacht wurde, wird als Ressource gekennzeichnet. Jeder REST-konforme Dienst hat eine eindeutige Adresse, den <a href="Uniform_Resource_Locator" title="Uniform Resource Locator">Uniform Resource Locator</a> (URL). Diese „Straße und Hausnummer im Netz“ standardisiert den Zugriffsweg zum Angebot eines Webservices für eine Vielzahl von Anwendungen (Clients). Eine konsistente Adressierbarkeit erleichtert es außerdem, einen Webservice als Teil eines <a href="Mashup_(Internet)" title="Mashup (Internet)">Mashups</a> weiterzuverwenden.

<div class="mw-heading mw-heading4"><h4 id="Repräsentationen_zur_Veränderung_von_Ressourcen">Repräsentationen zur Veränderung von Ressourcen</h4></div>

Die unter einer Adresse zugänglichen Dienste können unterschiedliche Darstellungsformen (Repräsentationen) haben. Ein REST-konformer Server kann je nachdem, was die Anwendung anfordert, verschiedene Repräsentationen einer Ressource ausliefern, z. B. in verschiedenen Sprachen oder Formaten (<a href="Hypertext_Markup_Language" title="Hypertext Markup Language">HTML</a>, <a href="JavaScript_Object_Notation" class="mw-redirect" title="JavaScript Object Notation">JSON</a> oder <a href="Extensible_Markup_Language" title="Extensible Markup Language">XML</a>) oder auch die Beschreibung oder Dokumentation des Dienstes. Diese Repräsentation enthält alle nötigen Informationen zur Veränderung der Ressource und muss nicht der intern vom Server verwendeten Repräsentation entsprechen (z. B. die Repräsentation zwischen Client und Server wird als JSON ausgetauscht, intern speichert der Server die Informationen aber in verschiedenen Spalten einer <a href="Relationale_Datenbank" title="Relationale Datenbank">relationalen Datenbank</a> ab).

Die Veränderung einer Ressource (also deren aktuellen Status) soll nur über eine Repräsentation erfolgen.

<div class="mw-heading mw-heading4"><h4 id="Selbstbeschreibende_Nachrichten">Selbstbeschreibende Nachrichten</h4></div>

REST-Nachrichten sollen selbstbeschreibend sein. Dazu zählt u. a. die Verwendung von Standardmethoden. Über diese Standardmethoden lassen sich Ressourcen manipulieren. Als Beispiel seien an dieser Stelle die HTTP-Verben genannt; Details siehe unten.

<div class="mw-heading mw-heading4"><h4 id="„Hypermedia_as_the_Engine_of_Application_State“_(HATEOAS)">„Hypermedia as the Engine of Application State“ (HATEOAS)</h4></div>

Dies ist laut Fielding die wichtigste Eigenschaft; siehe <a href="#HATEOAS">unten</a>.

<div class="mw-heading mw-heading3"><h3 id="Mehrschichtige_Systeme">Mehrschichtige Systeme</h3></div>

Die Systeme sollen mehrschichtig aufgebaut sein. Dadurch reicht es, dem Anwender lediglich eine Schnittstelle anzubieten. Dahinterliegende Ebenen können verborgen bleiben und somit die Architektur insgesamt vereinfacht werden. Vorteile dabei sind die bessere Skalierbarkeit der Server sowie eine mögliche Abkapselung durch Firewalls. Durch Cache-Speicher an den Grenzen (z. B. vom Server zum Web) kann die Effizienz der Anfragen erhöht werden; siehe Caching.

<div class="mw-heading mw-heading3"><h3 id="Code_on_Demand_(optional)">Code on Demand (optional)</h3></div>

Diese Forderung von Fielding ist optional. Unter Code on Demand ist zu verstehen, dass erst im Bedarfsfall an den Client Code zur lokalen Ausführung übertragen werden kann.

Ein Beispiel hierfür wäre die Übertragung von JavaScript-Code bei einer HTML-Repräsentation.

<div class="mw-heading mw-heading2"><h2 id="Umsetzung">Umsetzung</h2></div>

Für die Umsetzung des REST-Paradigmas wird ein zustandsloses Client-Server-Protokoll verwendet. Als Anwendungsschicht-Protokolle werden hauptsächlich <a href="Hypertext_Transfer_Protocol" title="Hypertext Transfer Protocol">HTTP</a> und <a href="Hypertext_Transfer_Protocol_Secure" title="Hypertext Transfer Protocol Secure">HTTPS</a> eingesetzt. Das liegt unter anderem daran, dass sich diese im WWW etabliert haben, über einen vergleichsweise einfachen Aufbau verfügen und mit so gut wie jeder <a href="Firewall" title="Firewall">Firewall</a> kompatibel sind. REST vereinheitlicht die Schnittstelle zwischen Systemen auf eine überschaubare und bezüglich des zu erwartenden Verhaltens standardisierte Menge von Aktionen. Welche Aktionen dies sind, ist in REST nicht festgelegt, aber alle Aktionen sind allgemein definiert, in der Regel durch die verwendeten Protokolle der Anwendungsschicht.

Während REST als Abstraktion des WWW keine spezielle <a href="Implementierung" title="Implementierung">Implementierung</a> und kein spezielles Protokoll fordert, ist doch zu beobachten, dass fast ausschließlich HTTP verwendet wird, wodurch auch die Menge der Aktionen festgelegt ist.

Wird über HTTP zugegriffen, so gibt die verwendete HTTP-Methode, darunter <code>GET</code>, <code>POST</code>, <code>PUT</code> und <code>DELETE</code>, an, welche Operation des Dienstes gewünscht ist.

HTTP schreibt vor, dass <code>GET</code> „sicher“ (<a href="Englische_Sprache" title="Englische Sprache">englisch</a> safe) sein muss, was bedeutet, dass diese Methode nur Informationen beschafft und keine sonstigen Effekte verursacht. Die Methoden <code>GET</code>, <code>HEAD</code>, <code>PUT</code> und <code>DELETE</code> müssen laut HTTP-Spezifikation <a href="Idempotenz" title="Idempotenz">idempotent</a> sein, was in diesem Zusammenhang bedeutet, dass das mehrfache Absenden der gleichen Anforderung sich nicht anders auswirkt als ein einzelner Aufruf.<a href="#cite_note-4">[4]</a>

REST-Clients, die HTTP verwenden, können folgende Befehle absetzen, um Ressourcen anzufordern oder zu verändern:

<th>Befehl (HTTP-Methode)</th>

<th>Beschreibung</th>

<th>Anmerkungen

</th></tr>

<tr>

<td>GET

</td>

<td>Fordert die angegebene Ressource vom Server an. GET weist keine Nebeneffekte auf. Der Zustand am Server wird nicht verändert, weshalb GET als sicher bezeichnet wird.

</td>

</td></tr>

<tr>

<td>POST

</td>

<td>Fügt eine neue (Sub-)Ressource unterhalb der angegebenen Ressource ein. Da die neue Ressource noch keinen URI besitzt, adressiert der URI die übergeordnete Ressource. Als Ergebnis wird der neue Ressourcenlink dem Client zurückgegeben. POST kann im weiteren Sinne auch dazu verwendet werden, Operationen abzubilden, die von keiner anderen Methode abgedeckt werden.

</td>

</td></tr>

<tr>

<td>PUT

</td>

<td>Die angegebene Ressource wird angelegt. Wenn die Ressource bereits existiert, wird sie geändert.

</td>

</td></tr>

<tr>

<td>PATCH<a href="#cite_note-patch-8">[n 4]</a>

</td>

<td>Ein Teil der angegebenen Ressource wird geändert. Hierbei sind Nebeneffekte erlaubt.

</td>

</td></tr>

<tr>

<td>DELETE

</td>

<td>Löscht die angegebene Ressource.

</td>

</td></tr>

<tr>

<td>HEAD

</td>

<td>Fordert Metadaten zu einer Ressource an.

</td>

</td></tr>

<tr>

<td>OPTIONS

</td>

<td>Prüft, welche Methoden auf einer Ressource zur Verfügung stehen.

</td>

</td></tr>

<tr>

<td>CONNECT

</td>

<td>Dient dazu, die Anfrage durch einen TCP-Tunnel zu leiten. Wird meist eingesetzt, um eine HTTPS-Verbindung über einen HTTP-Proxy herzustellen.

</td>

</td></tr>

<tr>

<td>TRACE

</td>

<td>Gibt die Anfrage zurück, wie sie der Zielserver erhält. Dient etwa dazu, um Änderungen der Anfrage durch Proxyserver zu ermitteln.

</td>

</td></tr>

nullipotent. Ein Aufruf dieser Methoden führt zu keinen Nebeneffekten.

</li>

nicht idempotent. Ein erneuter Aufruf erstellt für jeden Aufruf mit demselben URI ein neues Objekt, anstatt dasselbe Objekt zurückzugeben.

</li>

<a href="Idempotenz" title="Idempotenz">idempotent</a>. Der erste Aufruf dieser Methoden mit einem bestimmten URI führt zu Nebeneffekten. Ein erneuter Aufruf mit demselben URI führt zu keinen weiteren Nebeneffekten.

</li>

/* start https://de.wikipedia.org/ */

.mw-parser-output .dewiki-iconexternal>a{background-position:center right!important;background-repeat:no-repeat!important}body.skin-minerva .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/OOjs_UI_icon_external-link-ltr-progressive.svg")!important;background-size:10px!important;padding-right:13px!important}body.skin-timeless .mw-parser-output .dewiki-iconexternal>a,body.skin-monobook .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/MediaWiki_external_link_icon.svg")!important;padding-right:13px!important}body.skin-vector .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/Link.ernal-small-ltr-progressive.svg")!important;background-size:0.857em!important;padding-right:1em!important}

/* end https://de.wikipedia.org/ */

</style><a href="https://datatracker.ietf.org/doc/html/rfc5789" class="extiw external" title="rfc:5789">5789</a> – PATCH Method for HTTP. März 2010 (englisch).

</li>

optional. Wird nicht für <a href="CRUD" title="CRUD">CRUD</a>-Operationen benötigt.

</li>

Eine Implementierung dieser Methoden wirkt sich ggf. auf die Sicherheit der Anwendung aus.

</li>

</ol>

</td></tr></tbody></table>

Abhängig von der Implementierung können noch weitere HTTP-Befehle unterstützt werden. Dazu gehören <code>COPY</code>, <code>MOVE</code>, <code>MKCOL</code>, <code>LOCK</code> und <code>UNLOCK</code> des <a href="WebDAV" title="WebDAV">WebDAV</a>-Protokolls<a href="#cite_note-WebDAVMethods-11">[5]</a>, sowie <code>LINK</code> und <code>UNLINK</code> aus RFC 2068.<a href="#cite_note-12">[6]</a> Bei der Kommunikation über UDP kann zudem das <a href="Constrained_Application_Protocol" title="Constrained Application Protocol">CoAP</a> aus RFC 7252<a href="#cite_note-13">[7]</a> statt HTTP eingesetzt werden, welches leicht abweichende Bedeutungen für <code>GET</code>, <code>POST</code>, <code>PUT</code> und <code>DELETE</code> besitzt.

<div class="mw-heading mw-heading2"><h2 id="Sicherheit">Sicherheit</h2></div>

Das Paradigma verlangt, dass alle Informationen, die eine Anwendung braucht, um den Seitenzustand wiederherzustellen, in der Anfrage enthalten sind. Dabei identifiziert der URI die Ressource, während im HTTP-Header Informationen wie Zugriffsart (GET, PUT), Rückgabeformat oder Authentifizierung enthalten sein können.

REST lässt sich für Webseiten und Webservices verwenden, die keine Authentifizierung erfordern oder diese auf anderem Wege (beispielsweise durch Prüfung der <a href="IP-Adresse" title="IP-Adresse">IP-Adresse</a>, durch <a href="HTTP-Authentifizierung" title="HTTP-Authentifizierung">HTTP-Authentifizierung</a> oder <a href="Transport_Layer_Security" title="Transport Layer Security">TLS</a>/<a href="Hypertext_Transfer_Protocol_Secure" title="Hypertext Transfer Protocol Secure">HTTPS</a>-Zertifikatsprüfung) erreichen, wodurch bereits viele Anwendungsfälle abgedeckt werden können. Alternativ können auch <a href="Token_(Rechnernetz)" title="Token (Rechnernetz)">Token</a>-basierte Verfahren wie <a href="Keyed-Hash_Message_Authentication_Code" class="mw-redirect" title="Keyed-Hash Message Authentication Code">HMAC</a>, <a href="OAuth" title="OAuth">OAuth</a>, <a href="JSON_Web_Token" title="JSON Web Token">JSON Web Token</a> oder <a href="OpenID" title="OpenID">OpenID</a> verwendet werden.

Da REST – im Gegensatz zu SOAP mit <a href="WS-Security" title="WS-Security">WS-Security</a> – selbst keine Verschlüsselungsmethoden definiert, wird bei sicherheitskritischen Nachrichten ein verschlüsseltes Transportprotokoll wie <a href="Hypertext_Transfer_Protocol_Secure" title="Hypertext Transfer Protocol Secure">HTTPS</a> verwendet.

Durch die Nutzung der HTTP-Methoden ist es für Firewalls möglich, die Anfrage zu verstehen, zu filtern und zu protokollieren. Ein Beispiel dafür wäre, dass alle PUT-Anfragen von einer externen Ressource abgelehnt werden können. Dadurch unterscheidet sich REST von beispielsweise <a href="SOAP" title="SOAP">SOAP</a>.

<div class="mw-heading mw-heading2"><h2 id="Versionierung">Versionierung</h2></div>

Um einen REST-Service zu versionieren, stehen mehrere Varianten zur Auswahl: über die DNS-Adresse, URL und mittels HTTP-Header.

Bei der DNS-Versionierung wird die Version als Bestandteil des Hostnamens behandelt.

<code>http://v1.api.example.com/customer/1234</code>

<code>http://v1_1.api.example.com/customer/1234</code>

<code>http://v2.api.example.com/customer/1234</code>

<code>http://v2_2.api.example.com/customer/1234</code>

Diese Variante ist, wegen der Verwaltung im DNS, üblicherweise mit hohem Aufwand verbunden. In der Praxis ist sie daher kaum anzutreffen.

Bei der URL-Versionierung wird die Version der Schnittstelle im Pfad der URL angegeben:

<code>http://example.com/api/v1/customer/1234</code>

<code>http://example.com/api/v1.1/customer/1234</code>

<code>http://example.com/api/v2.0/customer/1234</code>

<code>http://example.com/api/v2.2/customer/1234</code>

Die Versionierung über die URL ist die gebräuchlichste Variante.

Bei der Versionierung über den HTTP-Header wird die Version im Accept-HTTP-Header angegeben:

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>GET /api/customer/1234 HTTP/1.1

Host: example.com

Accept: application/xml,application/json;version=1

</pre></div>

Nach der Bereitstellung einer neuen Version des Services muss die alte Version des Endpunktes für eine bestimmte Zeit weiter bereitgestellt werden, um dem Nutzer Zeit zur Umstellung zu geben. Eine Clientanwendung sollte automatisch erkennen können, dass der Endpunkt obsolet ist, ohne den Endpunkt in der Nutzung einzuschränken. Dies kann mittels eines Warning-HTTP-Headers<a href="#cite_note-14">[8]</a> erfolgen:

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>HTTP/1.1 200 OK

Date: Sat, 11 Mar 2017 12:28:53 GMT

Server: Apache/2.2.14 (Win32)

Warning: 299 example.com/api/v1 "Deprecated API : use example.com/api/v1.1 instead. Old API maintained until 2017-06-02"

Content-Length: 88

Content-Type: application/json

Connection: Closed

</pre></div>

Der Client sollte die Warnung im <a href="Logdatei" title="Logdatei">Log</a> und in einer <a href="Operations-Datenbank" title="Operations-Datenbank">OpsDB</a> protokollieren, um es dem Betreiber des Clienten zu ermöglichen, rechtzeitig auf die neue API umzustellen.

Wird der alte Endpunkt weiter angeboten, sollte der neue Endpunkt mittels eines HTTP-Redirects unter der alten Adresse auffindbar sein:

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>GET /api/v1/customer/1234 HTTP/1.1

Host: example.com

Accept: application/xml,application/json

</pre></div>

<div class="mw-highlight mw-highlight-lang-text mw-content-ltr" dir="ltr"><pre>HTTP/1.1 302 Found

Location: example.com/api/v1.1/customer/1234

</pre></div>

Grundsätzlich ist es empfehlenswert, vor dem Auflassen eines obsoleten Endpunktes mittels <a href="Monitoring" title="Monitoring">Monitoring</a> zu prüfen, ob dieser Endpunkt noch aktiv verwendet wird. Zudem sollte mittels <a href="Operations-Datenbank" title="Operations-Datenbank">OpsDB</a> geprüft werden, ob es sich um einen Endpunkt handelt, der nur selten (z. B. quartalsweise) verwendet wird.

<div class="mw-heading mw-heading2"><h2 id="HATEOAS">HATEOAS</h2></div>

<div class="hauptartikel" role="navigation">→ Hauptartikel: <a href="HATEOAS" title="HATEOAS">HATEOAS</a></div>

HATEOAS steht für Hypermedia as the Engine of Application State und ist ein Entwurfsprinzip von REST-Architekturen. Bei HATEOAS navigiert der Client einer REST-Schnittstelle ausschließlich über URLs, die vom Server bereitgestellt werden.<a href="#cite_note-15">[9]</a>

Abhängig von der gewählten Repräsentation geschieht die Bereitstellung der URIs über <a href="Hypermedia" title="Hypermedia">Hypermedia</a>, also z. B.

<ul><li>in Form von „href“- und „src“-Attributen bei <a href="Hypertext_Markup_Language" title="Hypertext Markup Language">HTML</a>-Dokumenten bzw. HTML-Snippets, oder</li>

<li>in für die jeweilige Schnittstelle definierten und dokumentierten JSON- bzw. XML-Attributen/-Elementen.</li></ul>

Abstrakt betrachtet stellen HATEOAS-konforme REST-Services einen <a href="Endlicher_Automat" title="Endlicher Automat">endlichen Automaten</a> dar, dessen Zustandsveränderungen durch die Navigation mittels der bereitgestellten URIs erfolgt.

Durch HATEOAS ist eine lose Bindung gewährleistet und die Schnittstelle kann verändert werden. Im Gegensatz dazu kommuniziert ein SOAP-basierter Webservice über ein fixiertes Interface. Für eine Änderung des Service muss hier eine neue Schnittstelle bereitgestellt werden und in der <a href="Schnittstellenbeschreibungssprache" title="Schnittstellenbeschreibungssprache">Schnittstellenbeschreibung</a> (ein <a href="Web_Services_Description_Language" title="Web Services Description Language">WSDL</a>-Dokument) definiert werden. Registrierungsdatenbanken oder ähnliche Infrastrukturen, die z. B. bei <a href="Remote_Function_Call" title="Remote Function Call">Remote Function Call</a> erforderlich sind, werden bei HATEOAS nicht benötigt.

Zur Abbildung von HATEOAS gibt es unterschiedliche Standards. Hierzu gehören:<a href="#cite_note-16">[10]</a>

<li><a href="JSON-LD" title="JSON-LD">JSON-LD</a> und <a rel="nofollow" class="external text" href="http://www.markus-lanthaler.com/hydra/">Hydra</a></li>

<li><a rel="nofollow" class="external text" href="http://amundsen.com/media-types/collection/">Collection+JSON</a></li>

<li><a rel="nofollow" class="external text" href="https://github.com/kevinswiber/siren">Siren</a></li></ul>

<div class="mw-heading mw-heading3"><h3 id="Beispiel">Beispiel</h3></div>

Im Beispiel sieht man einen GET-Request, der Konto-Informationen im JSON-Format abruft:

<div class="mw-highlight mw-highlight-lang-http mw-content-ltr" dir="ltr"><pre>GET /accounts/123abc HTTP/1.1

Host: bank.example.com

Accept: application/json

...

</pre></div>

Die Antwort bei einem ausgeglichenen Konto kann dann wie folgt lauten:

<div class="mw-highlight mw-highlight-lang-http mw-content-ltr" dir="ltr"><pre>HTTP/1.1 200 OK

Content-Type: application/json

Content-Length: ...

{

"account": {

"account_id": "123abc",

"balance": {

"currency": "EUR",

"value": 100.0

},

"links": {

"deposit": "/accounts/123abc/deposit",

"withdraw": "/accounts/123abc/withdraw",

"transfer": "/accounts/123abc/transfer",

"close": "/accounts/123abc/close"

}

}

</pre></div>

Beispielantwort 1

Die Beispielantwort 1 beinhaltet vier mögliche Links: <code>deposit</code> (einzahlen), <code>withdraw</code> (abbuchen), <code>transfer</code> (überweisen) und <code>close</code> (kündigen). Wenn das Konto überzogen ist, kann nur noch Geld auf das Konto eingezahlt werden, aber keines mehr abgebucht oder überwiesen werden, und man kann das Konto nicht mehr kündigen. Die Antwort bei einem überzogenen Konto kann daher so aussehen:

Content-Type: application/json

Content-Length: ...

{

"account": {

"account_id": "123abc",

"balance": {

"currency": "EUR",

"value": -100.0

},

"links": {

"deposit": "/accounts/123abc/deposit"

}

}

</pre></div>

Beispielantwort 2

<div class="mw-heading mw-heading2"><h2 id="Richardson_Maturity_Model">Richardson Maturity Model</h2></div>

Das Richardson Maturity Model (RMM, deutsch Richardson-Reifegradmodell) ist ein von Leonard Richardson entwickelter Maßstab, der angibt, wie strikt ein Service REST implementiert.

<caption>Richardson Maturity Model<a href="#cite_note-RMM-17">[11]</a>

</caption>

<th>Level</th>

<th>Eigenschaften

</th></tr>

<tr>

<td>

<ul><li>verwendet <a href="XML-RPC" title="XML-RPC">XML-RPC</a> oder <a href="SOAP" title="SOAP">SOAP</a></li>

<li>der Service wird über einen einzelnen URI adressiert</li>

<li>verwendet eine einzelne HTTP-Methode (oft POST)</li></ul>

</td></tr>

<tr>

<td>

<ul><li>verwendet verschiedene URIs und Ressourcen</li>

<li>verwendet eine einzelne HTTP-Methode (oft POST)</li></ul>

</td></tr>

<tr>

<td>

<ul><li>verwendet verschiedene URIs und Ressourcen</li>

<li>verwendet mehrere HTTP-Methoden</li></ul>

</td></tr>

<tr>

<td>

<ul><li>basiert auf HATEOAS und verwendet daher <a href="Hypermedia" title="Hypermedia">Hypermedia</a> für Navigation</li>

<li>verwendet verschiedene URIs und Ressourcen</li>

<li>verwendet mehrere HTTP-Methoden</li></ul>

</td></tr></tbody></table>

<div class="mw-heading mw-heading2"><h2 id="Abgrenzung_zu_anderen_Kommunikationsmechanismen">Abgrenzung zu anderen Kommunikationsmechanismen</h2></div>

Bei REST handelt es sich um ein Programmierparadigma, welches mit verschiedenen Mechanismen implementiert werden kann. Eine Neuerung ist dabei die Verwendung möglichst vieler <a href="Hypertext_Transfer_Protocol" title="Hypertext Transfer Protocol">HTTP</a>-Methoden in Verbindung mit der auszuführenden Aktion. Im Gegensatz dazu wird zum Beispiel SOAP im Wesentlichen mit der POST-Methode verwendet. Der Unterschied liegt also mehr in der breiteren Verwendung von HTTP als Protokoll und URI als Identifizierungsmechanismus für konkrete Objekte. In der Vergangenheit wurden im Gegensatz dazu SOAP-Schnittstellen <a href="Remote_Procedure_Call" title="Remote Procedure Call">RPC</a>-basiert aufgebaut. Zu den Schwächen von SOAP gehören dabei der recht große Overhead mit vielen Meta- und wenig Nutzdaten sowie das rechenintensive Bauen der XML-Nachrichten. Darüber hinaus gibt es mittlerweile zahlreiche schwer zu überblickende Substandards.<a href="#cite_note-18">[12]</a>

Die engen Vorgaben von REST helfen dagegen, gut strukturierte Dienste zu bauen, und unterstützen die Verwendung von <a href="Clean_URL" title="Clean URL">Clean URLs</a>.

<div class="mw-heading mw-heading2"><h2 id="Siehe_auch">Siehe auch</h2></div>

<ul><li><a href="Java_API_for_RESTful_Web_Services" class="mw-redirect" title="Java API for RESTful Web Services">Java API for RESTful Web Services</a> (JAX-RS)</li>

<li><a href="Web_Application_Description_Language" title="Web Application Description Language">Web Application Description Language</a> – Beschreibungssprache für REST-basierte Dienste</li>

<li><a href="JSON-RPC" title="JSON-RPC">JSON-RPC</a> – JSON basiertes RPC-Protokoll</li>

<li><a href="Open_Data_Protocol" title="Open Data Protocol">Open Data Protocol</a> (OData)</li>

<li><a href="OpenAPI" title="OpenAPI">OpenAPI</a> – Spezifikation zur Beschreibung von REST-Schnittstellen</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Literatur">Literatur</h2></div>

<ul><li>Leonard Richardson, Sam Ruby: <cite style="font-style:italic">Web Services mit REST</cite>. O’Reilly Verlag, 2007, ISBN 978-3-89721-727-0.<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Representational+State+Transfer&rft.au=Leonard+Richardson%2C+Sam+Ruby&rft.btitle=Web+Services+mit+REST&rft.date=2007&rft.genre=book&rft.isbn=9783897217270&rft.pub=O%E2%80%99Reilly+Verlag" style="display:none"> </li>

<li>Stefan Tilkov et al.: <cite style="font-style:italic">REST und HTTP</cite>. Entwicklung und Integration nach dem Architekturstil des Web. 3., aktualisierte und erweiterte Auflage. dpunkt Verlag, 2015, ISBN 978-3-86490-120-1.<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Representational+State+Transfer&rft.au=Stefan+Tilkov+et+al.&rft.btitle=REST+und+HTTP&rft.date=2015&rft.edition=3.%2C+aktualisierte+und+erweiterte+Auflage&rft.genre=book&rft.isbn=9783864901201&rft.pub=dpunkt+Verlag" style="display:none"> </li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<ul><li>Roy Thomas Fielding: <a rel="nofollow" class="external text" href="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm">Architectural Styles and the Design of Network-based Software Architectures.</a> Abgerufen am 6. April 2013 (englisch, Dissertation, in der REST beschrieben wird).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ARepresentational+State+Transfer&rft.title=Architectural+Styles+and+the+Design+of+Network-based+Software+Architectures&rft.description=Architectural+Styles+and+the+Design+of+Network-based+Software+Architectures&rft.identifier=http%3A%2F%2Fwww.ics.uci.edu%2F%7Efielding%2Fpubs%2Fdissertation%2Ftop.htm&rft.creator=Roy+Thomas+Fielding&rft.language=en"> </li>

<li>Roy Thomas Fielding: <a rel="nofollow" class="external text" href="http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven">REST APIs must be hypertext-driven.</a> 20. September 2008, abgerufen am 7. April 2013 (englisch, Empfehlungen zum Entwerfen von REST-Schnittstellen mit HATEOAS).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ARepresentational+State+Transfer&rft.title=REST+APIs+must+be+hypertext-driven&rft.description=REST+APIs+must+be+hypertext-driven&rft.identifier=http%3A%2F%2Froy.gbiv.com%2Funtangled%2F2008%2Frest-apis-must-be-hypertext-driven&rft.creator=Roy+Thomas+Fielding&rft.date=2008-09-20&rft.language=en"> </li>

<li>David Megginson: <a rel="nofollow" class="external text" href="http://quoderat.megginson.com/2007/02/15/rest-the-quick-pitch">The quick pitch.</a> In: Quoderat. 15. Februar 2007, abgerufen am 6. April 2013 (englisch, Pragmatische Empfehlungen für die Anwendung von REST).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ARepresentational+State+Transfer&rft.title=The+quick+pitch&rft.description=The+quick+pitch&rft.identifier=http%3A%2F%2Fquoderat.megginson.com%2F2007%2F02%2F15%2Frest-the-quick-pitch&rft.creator=David+Megginson&rft.date=2007-02-15&rft.language=en"> </li>

<li>Thomas Bayer: <a rel="nofollow" class="external text" href="http://www.oio.de/public/xml/rest-webservices.htm">REST Web Services.</a> Orientation in Objects, November 2002, abgerufen am 6. April 2013 (Einführung in RESTful Web Services).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ARepresentational+State+Transfer&rft.title=REST+Web+Services&rft.description=REST+Web+Services&rft.identifier=http%3A%2F%2Fwww.oio.de%2Fpublic%2Fxml%2Frest-webservices.htm&rft.creator=Thomas+Bayer&rft.publisher=Orientation+in+Objects&rft.date=2002-11&rft.language=de"> </li>

<li>Alex Rodriguez: <a rel="nofollow" class="external text" href="http://www.ibm.com/developerworks/webservices/library/ws-restful/">RESTful Web services: The basics.</a> In: developerWorks. <a href="IBM" title="IBM">IBM</a>, 6. November 2008, abgerufen am 6. April 2013 (englisch, Basisprinzipien von REST).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ARepresentational+State+Transfer&rft.title=RESTful+Web+services%3A+The+basics&rft.description=RESTful+Web+services%3A+The+basics&rft.identifier=http%3A%2F%2Fwww.ibm.com%2Fdeveloperworks%2Fwebservices%2Flibrary%2Fws-restful%2F&rft.creator=Alex+Rodriguez&rft.publisher=%5B%5BIBM%5D%5D&rft.date=2008-11-06&rft.language=en"> </li>

<li>Stefan Tilkov: <a rel="nofollow" class="external text" href="http://jaxenter.de/artikel/REST-bessere-Web-Service-167838">REST – Der bessere Web Service?</a> In: jaxenter. IT-Republik, Februar 2009, abgerufen am 6. April 2013 (Grundlagen der REST-Architektur).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ARepresentational+State+Transfer&rft.title=REST+%E2%80%93+Der+bessere+Web+Service%3F&rft.description=REST+%E2%80%93+Der+bessere+Web+Service%3F&rft.identifier=http%3A%2F%2Fjaxenter.de%2Fartikel%2FREST-bessere-Web-Service-167838&rft.creator=Stefan+Tilkov&rft.publisher=IT-Republik&rft.date=2009-02&rft.language=de"> </li>

<li>Gregor Roth: <a rel="nofollow" class="external text" href="http://www.infoq.com/articles/designing-restful-http-apps-roth">RESTful HTTP in practice.</a> InfoQ, 18. August 2009, abgerufen am 6. April 2013 (englisch, REST in der Praxis).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ARepresentational+State+Transfer&rft.title=RESTful+HTTP+in+practice&rft.description=RESTful+HTTP+in+practice&rft.identifier=http%3A%2F%2Fwww.infoq.com%2Farticles%2Fdesigning-restful-http-apps-roth&rft.creator=Gregor+Roth&rft.publisher=InfoQ&rft.date=2009-08-18&rft.language=en"> </li></ul>

<div class="mw-heading mw-heading2"><h2 id="Einzelnachweise">Einzelnachweise</h2></div>

<li id="cite_note-fielding_experiences-1"><a href="#cite_ref-fielding_experiences_1-0">↑</a> Roy Fielding: <a rel="nofollow" class="external text" href="https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm">6: Experience and Evaluation.</a> In: Architectural Styles and the Design of Network-based Software Architectures. 2000, abgerufen am 15. Juni 2015 (englisch).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ARepresentational+State+Transfer&rft.title=6%3A+Experience+and+Evaluation&rft.description=6%3A+Experience+and+Evaluation&rft.identifier=https%3A%2F%2Fwww.ics.uci.edu%2F%7Efielding%2Fpubs%2Fdissertation%2Fevaluation.htm&rft.creator=Roy+Fielding&rft.date=2000&rft.language=en">

</li>

<li id="cite_note-2"><a href="#cite_ref-2">↑</a> Roy Thomas Fielding: <cite style="font-style:italic">Architectural Styles and the Design of Network-based Software Architectures – Dissertation</cite>. 2000 (<a rel="nofollow" class="external text" href="https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation_2up.pdf">Volltext</a> [PDF; 900 kB; abgerufen am 6. Januar 2021]).<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Representational+State+Transfer&rft.au=Roy+Thomas+Fielding&rft.btitle=Architectural+Styles+and+the+Design+of+Network-based+Software+Architectures+-+Dissertation&rft.date=2000&rft.genre=book" style="display:none">

</li>

<li id="cite_note-3"><a href="#cite_ref-3">↑</a> Roy Thomas Fielding: <cite style="font-style:italic">Architectural Styles and the Design of Network-based Software Architectures – Dissertation</cite>. 2000, S. 79 ff.<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rfr_id=info:sid/de.wikipedia.org:Representational+State+Transfer&rft.au=Roy+Thomas+Fielding&rft.btitle=Architectural+Styles+and+the+Design+of+Network-based+Software+Architectures+-+Dissertation&rft.date=2000&rft.genre=book&rft.pages=79ff" style="display:none">

</li>

<li id="cite_note-4"><a href="#cite_ref-4">↑</a> Fielding et al.: <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc2616#section-9" class="extiw external" title="rfc:2616">2616</a> – Hypertext Transfer Protocol – HTTP/1.1. Juni 1999, Abschnitt 9: Method Definitions. (englisch).

</li>

<li id="cite_note-WebDAVMethods-11"><a href="#cite_ref-WebDAVMethods_11-0">↑</a> <a rel="nofollow" class="external text" href="https://msdn.microsoft.com/en-us/library/aa142917.aspx?f=255&MSPPError=-2147217396">WebDAV Methods.</a> In: <a href="Microsoft_Developer_Network" title="Microsoft Developer Network">MSDN</a>. Juni 2007, abgerufen am 13. Februar 2016 (englisch).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ARepresentational+State+Transfer&rft.title=WebDAV+Methods&rft.description=WebDAV+Methods&rft.identifier=https%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Faa142917.aspx%3Ff%3D255%26MSPPError%3D-2147217396&rft.date=2007-06&rft.language=en">

</li>

<li id="cite_note-12"><a href="#cite_ref-12">↑</a> Fielding et al.: <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc2068" class="extiw external" title="rfc:2068">2068</a> – Hypertext Transfer Protocol – HTTP/1.1. Januar 1997 (englisch).

</li>

<li id="cite_note-13"><a href="#cite_ref-13">↑</a> <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc7252" class="extiw external" title="rfc:7252">7252</a> – The Constrained Application Protocol (CoAP). Juni 2014 (englisch).

</li>

<li id="cite_note-14"><a href="#cite_ref-14">↑</a> <a href="Request_for_Comments" title="Request for Comments">RFC</a>: <a href="https://datatracker.ietf.org/doc/html/rfc7234#section-5.5" class="extiw external" title="rfc:7234">7234</a> – Hypertext Transfer Protocol (HTTP/1.1): Caching. Juni 2014, Abschnitt 5.5: Warning. (englisch).

</li>

<li id="cite_note-15"><a href="#cite_ref-15">↑</a> Andreas Würl, Jörg Adler: <a rel="nofollow" class="external text" href="https://www.heise.de/developer/artikel/Hoechster-Reifegrad-fuer-REST-mit-HATEOAS-3550392.html">Höchster Reifegrad für REST mit HATEOAS.</a> <a href="Verlag_Heinz_Heise" class="mw-redirect" title="Verlag Heinz Heise">Heise</a>, 6. Dezember 2016, abgerufen am 6. Januar 2021.<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ARepresentational+State+Transfer&rft.title=H%C3%B6chster+Reifegrad+f%C3%BCr+REST+mit+HATEOAS&rft.description=H%C3%B6chster+Reifegrad+f%C3%BCr+REST+mit+HATEOAS&rft.identifier=https%3A%2F%2Fwww.heise.de%2Fdeveloper%2Fartikel%2FHoechster-Reifegrad-fuer-REST-mit-HATEOAS-3550392.html&rft.creator=Andreas+W%C3%BCrl%2C+J%C3%B6rg+Adler&rft.publisher=%5B%5BVerlag+Heinz+Heise%7CHeise%5D%5D&rft.date=2016-12-06">

</li>

<li id="cite_note-16"><a href="#cite_ref-16">↑</a> Kevin Sookocheff: <a rel="nofollow" class="external text" href="https://sookocheff.com/post/api/on-choosing-a-hypermedia-format/">On choosing a hypermedia type for your API – HAL, JSON-LD, Collection+JSON, SIREN, Oh My!</a> 11. März 2014, abgerufen am 11. Juni 2017 (englisch).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ARepresentational+State+Transfer&rft.title=On+choosing+a+hypermedia+type+for+your+API+%E2%80%93+HAL%2C+JSON-LD%2C+Collection%2BJSON%2C+SIREN%2C+Oh+My%21&rft.description=On+choosing+a+hypermedia+type+for+your+API+%E2%80%93+HAL%2C+JSON-LD%2C+Collection%2BJSON%2C+SIREN%2C+Oh+My%21&rft.identifier=https%3A%2F%2Fsookocheff.com%2Fpost%2Fapi%2Fon-choosing-a-hypermedia-format%2F&rft.creator=Kevin+Sookocheff&rft.date=2014-03-11&rft.language=en">

</li>

<li id="cite_note-RMM-17"><a href="#cite_ref-RMM_17-0">↑</a> <a href="Martin_Fowler" title="Martin Fowler">Martin Fowler</a>: <a rel="nofollow" class="external text" href="http://martinfowler.com/articles/richardsonMaturityModel.html">Richardson Maturity Model.</a> 18. März 2010, abgerufen am 7. April 2013 (englisch, Erklärung des REST Maturity Models (RMM)).<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ARepresentational+State+Transfer&rft.title=Richardson+Maturity+Model&rft.description=Richardson+Maturity+Model&rft.identifier=http%3A%2F%2Fmartinfowler.com%2Farticles%2FrichardsonMaturityModel.html&rft.creator=%5B%5BMartin+Fowler%5D%5D&rft.date=2010-03-18&rft.language=en">

</li>

<li id="cite_note-18"><a href="#cite_ref-18">↑</a> Martin Helmich: <a rel="nofollow" class="external text" href="https://www.mittwald.de/blog/webentwicklung-design/webentwicklung/restful-webservices-1-was-ist-das-uberhaupt">RESTful Webservices (1): Was ist das überhaupt?</a> 12. März 2013, abgerufen am 16. November 2017.<span style="display: none;" class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&rfr_id=info%3Asid%2Fde.wikipedia.org%3ARepresentational+State+Transfer&rft.title=RESTful+Webservices+%281%29%3A+Was+ist+das+%C3%BCberhaupt%3F&rft.description=RESTful+Webservices+%281%29%3A+Was+ist+das+%C3%BCberhaupt%3F&rft.identifier=https%3A%2F%2Fwww.mittwald.de%2Fblog%2Fwebentwicklung-design%2Fwebentwicklung%2Frestful-webservices-1-was-ist-das-uberhaupt&rft.creator=Martin+Helmich&rft.date=2013-03-12">

</li>

</ol>

/* start https://de.wikipedia.org/ */

.mw-parser-output table.erw-nav-zebra>tbody>:nth-child(odd){background-color:var(--dewiki-hintergrundfarbe-basis)}.mw-parser-output .erw-nav-farbschema-blau .erw-nav-leiste{background-color:#f5f5f5}.mw-parser-output .erw-nav-farbschema-blau .erw-nav-gruppe{background-color:#e5ecf2}.mw-parser-output .erw-nav-farbschema-grau .erw-nav-leiste,.mw-parser-output .erw-nav-farbschema-grau .erw-nav-gruppe{background-color:#ececec}.mw-parser-output .erweiterte-navigationsleiste .klappleiste-inhalt>.wikitable>*>tr{border-top:2px solid #fdfdfd!important;border-bottom:2px solid #fdfdfd!important}@media screen{html.skin-theme-clientpref-night .mw-parser-output .erw-nav-farbschema-blau .erw-nav-leiste,html.skin-theme-clientpref-night .mw-parser-output .erw-nav-farbschema-blau .erw-nav-gruppe,html.skin-theme-clientpref-night .mw-parser-output .erw-nav-farbschema-grau .erw-nav-leiste,html.skin-theme-clientpref-night .mw-parser-output .erw-nav-farbschema-grau .erw-nav-gruppe{background-color:#202122}html.skin-theme-clientpref-night .mw-parser-output .erweiterte-navigationsleiste .klappleiste-inhalt .wikitable tr,html.skin-theme-clientpref-night .mw-parser-output .erweiterte-navigationsleiste .klappleiste-inhalt .wikitable td{border-color:#101418!important}html.skin-theme-clientpref-night .mw-parser-output .erw-nav-bild span[typeof="mw:File"] img{background-color:#c8ccd1}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .erw-nav-farbschema-blau .erw-nav-leiste,html.skin-theme-clientpref-os .mw-parser-output .erw-nav-farbschema-blau .erw-nav-gruppe,html.skin-theme-clientpref-os .mw-parser-output .erw-nav-farbschema-grau .erw-nav-leiste,html.skin-theme-clientpref-os .mw-parser-output .erw-nav-farbschema-grau .erw-nav-gruppe{background-color:#202122}html.skin-theme-clientpref-os .mw-parser-output .erweiterte-navigationsleiste .klappleiste-inhalt .wikitable tr,html.skin-theme-clientpref-os .mw-parser-output .erweiterte-navigationsleiste .klappleiste-inhalt .wikitable td{border-color:#101418!important}html.skin-theme-clientpref-os .mw-parser-output .erw-nav-bild span[typeof="mw:File"] img{background-color:#c8ccd1}}.mw-parser-output .erweiterte-navigationsleiste .hlist .wikitable{border-top:0px!important;border-bottom:0px!important;margin-top:0!important;margin-bottom:0!important}.mw-parser-output .erweiterte-navigationsleiste .hlist .wikitable tr:first-of-type td{border-top:0px!important}.mw-parser-output .erweiterte-navigationsleiste .hlist .wikitable tr:last-of-type td{border-bottom:0px!important}

/* end https://de.wikipedia.org/ */

</style><style data-mw-deduplicate="TemplateStyles:r260755238">

/* start https://de.wikipedia.org/ */

.mw-parser-output div.klappleiste{border:1px solid var(--dewiki-rahmenfarbe1);clear:both;font-size:95%;box-sizing:border-box;margin-top:1.5em;padding:2px}.mw-parser-output div.klappleiste:after{clear:both;content:"";display:block}.mw-parser-output div.klappleiste-bild{float:left;padding:2px}.mw-parser-output div.klappleiste-kopf{background:var(--dewiki-hintergrundfarbe5);color:var(--color-base,#202122);text-align:center;font-weight:bold}.mw-parser-output div.klappleiste.mw-collapsed .klappleiste-bild{display:none}.mw-parser-output div.klappleiste+div.klappleiste,.mw-parser-output div.klappleiste+link+div.klappleiste,.mw-parser-output div.klappleiste+link+link+div.klappleiste,.mw-parser-output div.klappleiste+link+style+div.klappleiste,.mw-parser-output div.klappleiste+style+div.klappleiste,.mw-parser-output div.klappleiste+style+style+div.klappleiste,.mw-parser-output div.klappleiste+style+link+div.klappleiste{margin-top:-1px}@media screen{html.skin-theme-clientpref-night .mw-parser-output .klappleiste-bild span[typeof="mw:File"]:not(.skin-invert-image) img{background-color:#c8ccd1}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .klappleiste-bild span[typeof="mw:File"]:not(.skin-invert-image) img{background-color:#c8ccd1}}

/* end https://de.wikipedia.org/ */

</style>

<div class="klappleiste-kopf">Webserver-Schnittstellen</div>

<td class="erw-nav-gruppe" style="white-space: nowrap;text-align: right;border: 1px solid transparent;border-top: 1px solid #FFF;border-bottom: 2px solid #FFF;padding: 0 1em;"><a href="Netzwerkprotokoll" title="Netzwerkprotokoll">Protokolle</a>

</td>

<a href="Common_Gateway_Interface" title="Common Gateway Interface">CGI</a> | <a href="Simple_Common_Gateway_Interface" title="Simple Common Gateway Interface">SCGI</a> | <a href="FastCGI" title="FastCGI">FastCGI</a> | <a href="Apache_JServ_Protocol" title="Apache JServ Protocol">AJP</a>

</td></tr>

<tr>

</td>

C NSAPI | C ASAPI | <a href="Internet_Server_API" title="Internet Server API">C ISAPI</a> | <a href="Jakarta_Servlet" title="Jakarta Servlet">Jakarta Servlet</a> | <a href="ASP.NET" title="ASP.NET">ASP.NET</a> | <a href="Web_Server_Gateway_Interface" title="Web Server Gateway Interface">Python WSGI</a> | <a href="Rack_(Webserver-Interface)" title="Rack (Webserver-Interface)">Ruby Rack</a> | JavaScript JSGI | <a href="Perl_Web_Server_Gateway_Interface" title="Perl Web Server Gateway Interface">PSGI</a> | Lua WSAPI

</td></tr>

<tr>

<td class="erw-nav-gruppe" style="white-space: nowrap;text-align: right;border: 1px solid transparent;border-top: 1px solid #FFF;border-bottom: 2px solid #FFF;padding: 0 1em;"><a href="Apache_HTTP_Server" title="Apache HTTP Server">Apache</a>-Module

</td>

</td></tr>

<tr>

<td class="erw-nav-gruppe" style="white-space: nowrap;text-align: right;border: 1px solid transparent;border-top: 1px solid #FFF;border-bottom: 1px solid #FFF;padding: 0 1em;">Web APIs

</td>

</td></tr>

</tbody></table></div></div>

<div>

Normdaten (Sachbegriff): <a href="Gemeinsame_Normdatei" title="Gemeinsame Normdatei">GND</a>: <a rel="nofollow" class="external text" href="https://d-nb.info/gnd/7592728-7">7592728-7</a> </div>

</div></div></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2025-12-18" href="https://de.wikipedia.org/wiki/?title=Representational_State_Transfer&oldid=262534821">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>